Add vault payment commands - #244

Summary

Add vault payment commands for Link and AgentCard. The CLI prepares payment credentials, displays provider actions and payment-method choices, attaches vaults to new browsers, and observes item state/events. It does not submit merchant payments.

Current interface

• Vaults: create --name, list, get <vault>, delete <vault>.
• Wallets: wallets create <vault> <key> --provider link|agentcard --spec '<json>' [--open]; wallets payment-methods <vault> <key>.
• Cards: cards create|update <vault> <key> --provider link|agentcard --spec '<json>'.
• Items: items list, items get [--wait 0..60] [--expand payment_methods] [--open], items invoke <vault> <key> <operation> [--open], items events [--after <event-id>] [--wait 0..60], and items delete.
• Browser attachment: browsers create --vault <id-or-name>; repeatable, up to 20 vaults, incompatible with pools.

The wallets, cards, and items commands are under kernel vaults. Vault selectors accept an ID or name; item selectors currently use the immutable key. --project/KERNEL_PROJECT is optional: omitted scope is resolved by the API, using the default project for org-wide credentials rather than listing all projects.

Specifications and behavior

--spec is a JSON specification object, not a {type, spec} envelope. The command supplies the item type and injects provider; an embedded provider must match the flag. Provider-specific flags have been removed. JSON values are passed through the SDK without defaults, normalization, or integer precision loss; the API validates required and optional fields. This includes Link purchase details, metadata, and expiry. Card updates replace the entire spec, including removing omitted optional fields.

Help includes provider-specific types and examples, with a sync comment linking to the published API spec. The README covers both provider flows, expansion syntax, updates, and lifecycle behavior.

• items get shows operation types/descriptions and shell-quoted copyable commands retaining the selected project. items invoke GETs the item again, checks the requested type against available_operations, then POSTs {"type":"<operation>"} to /operations. Availability is API-controlled, without local item/provider/state rules or an operation registry. It prints the updated item and supports --open and -o json. Requests do not automatically retry; waits are bounded observations, not readiness/payment guarantees.
• The current OpenAPI operation schema accepts only {"type":"authorize"} and forbids extra fields; no operation --spec flag is added. Future parameterless operations can be invoked by name when advertised. The dedicated cards authorize command is removed without an alias.
• Action and approval URLs print in full outside truncating tables. Non-delete commands support -o json; output preserves public fields and aliases while filtering unknown/opaque provider data and credential-bearing action URLs.
• API errors retain the standard code/message. Vault and item deletes treat any HTTP 404 as success with Deleted or not found; other errors fail. Existing non-vault delete commands are unchanged.
• Vault bindings are creation-only. Vault/item rename and provider-domain configuration are not exposed.

SDK

Use published github.com/kernel/kernel-go-sdk v0.100.0. The preview replacement and checksums are removed. CI no longer needs a private SDK token or GOPRIVATE configuration, and Go caching is restored. Nine existing browser SDK call sites use the released SDK's IDOrName path-field spelling.

No SDK repository files were changed.

Verification

• make test and make build pass locally; vault tests also pass with -race. All four README --spec examples parse as JSON objects.
• golangci-lint run --new-from-rev=origin/main: 0 issues.
• SDK v0.100.0 downloads into an empty module cache with private-module configuration disabled; go mod verify passes. README and repository Markdown docs contain no card-mode references.
• HTTP fixtures cover both providers, raw JSON preservation/validation, request envelopes, optional scope, API errors, deletion semantics, bounded waits, advertised-operation gating across types/providers/states, future operation names, operation GET/POST errors without retries, explicit action opening, shell-safe/project-aware invocation hints, expansions, output, and browser attachment/pool conflicts.
• Local CLI checks cover both providers' wallet/card specs, full URLs in 40/80/120-column terminals, delete/list behavior for invalid-project responses, and executing a copied GET operation hint against a fixture (project shell quoting preserved; exactly GET/GET/POST). No live payment credentials or payments were created for testing.